\chapter{Background}\label{C:Background}
The analysis of the sufficiency of testing processes for safety-critical
software systems demands a discussion of constraints. Of particular concern are
the constraints enforced upon software \textit{process}. While there certainly
are liabilities for releasing a product that is defective\footnote{Section 
\ref{S:Liability} details the different forms of liability that software is
vulnerable to.}, the \textit{behavior} of the developer is what is under
scrutiny here. The first part of this chapter reviews the current practices in
software engineering testing processes. We then examine the negligence concerns
regarding these processes.

\section{Current Practices in Software Testing}
Despite the evidence of ineffective safety assurance \cite{Leveson93,Maisel05},
current standards in the software industry illustrate that efforts are being
made to ensure the safety of mission critical software applications. Though
unapproved and unofficial to any governing body, the Software Engineering Code
of Ethics motivates these efforts towards safer software. The first principle of
the code requires that software engineers work consistently with the public
interest. More specifically, public interest principles state that software
engineers shall: 

\begin{quote}
``\textit{1.02. Moderate the interests of the software engineer, the
employer, the client and the users with the public good.}''\cite{SECODE}
\end{quote}
\begin{center}and\end{center}
\begin{quote}
``\textit{1.03. Approve software only if they have a well-founded belief that it
is safe, meets specifications, passes appropriate tests, and does not diminish
quality of life, diminish privacy or harm the environment. The ultimate effect
of the work should be to the public good.}''\cite{SECODE}
\end{quote}
\begin{center}and\end{center}
\begin{quote}
``\textit{1.04 Disclose to appropriate persons or authorities any actual or
potential danger to the user, the public, or the environment, that they
reasonably believe to be associated with software or related
documents.}''\cite{SECODE}
\end{quote}

With these (and other) principles in mind\footnote{The preamble, the entire
listing of ``Principle 1: PUBLIC'', and the short version of the remaining
principles of the Software Engineering Code of Ethics and Professional Practice
are listed in Appendix \ref{A:SECode}}, groups like the International Standards
Organization, the Software Engineering Institute, and the Institute of
Electrical and Electronics Engineers have developed standards and guidelines for
developers to improve software processes.

\subsection{ISO 9000-3}
The International Standards Organization put forth a quality management standard
known as ISO 9001 to describe a set of guidelines that will help organizations
achieve standards of quality that are recognized and respected throughout the
world. The ISO 9001 guidelines are not specifically designed for safety-critical
software (or even software at all), but provide models for quality assurance
in the design, development, production, installation, and servicing of systems
in general \cite{Kehoe96}.

The ISO 9000-3 is the application of ISO 9001 the development, supply, and
maintenance of software. In terms of testing, the ISO 9000-3 standard adopts a
phase approach, similar to the waterfall model as described in \cite{Royce70}.
The six phases, at a high level, are:
\singlespace
\begin{enumerate}
  \item System Engineering/System Analysis
  \item Software Requirements Analysis
  \item Design
  \item Implementation
  \item Testing
  \item Maintenance
\end{enumerate}
\doublespace

The ISO 9000-3 guideline does not dictate the use of any procedure or process in
particular, but rather identifies commonly accepted and sound practices that are
suggested for use in product development and maintenance. Each organization will
have to apply these suggestions to their processes as they see fit. Included in
the standard is a section on ``Testing and Validation''. The ISO lists
techniques for testing from the unit tests through system-level testing and on
to field tests. The guidelinee exhibits what a reasonable software developer
would do to test and validate his software.

According to ISO 9000-3, testing is a perpetual effort, taking place during the
entire product-development cycle. For example: during the requirements phase, a
team must develop a preliminary test plan and identify test cases. During the
design phase, the team develops test cases and updates the test plan. During
implementation, system-level test cases are populated and unit-level test cases
are executed. And during the test phase, the team conducts functional,
integration, and system tests and performs regression testing as needed. For
more information, refer to \cite{Kehoe96}.

\subsection{Capability Maturity Model for Software, Version 1.1}
The Capability Maturity Model (CMM) helps organizations achieve mature software
development practices. A mature organization, acording to the CMM, possesses an
organization-wide ability to manage software processes, communicates appropriate
planned processes to staff and employees, and updates its processes when
necessary \cite{CMM11}. Process is important because the law of negligence is
specifically concerned with process\footnote{See Section \ref{SS:Negligence}.}.

The Software Engineering Institute (SEI)\footnote{The SEI and Carnegie Mellon
University developed and released the CMM \cite{CMM11}.} defines process as
\begin{quote}
``\textit{a set of activities, methods, practices, and transformations that 
people use to develop and maintain software and the associated 
products}''\cite{CMM11}.
\end{quote}
A software organizations \textit{capability} describes the range of expected
results the organization is expected to achieve based on its processes and its
\textit{maturity} is the extent at which its processes are defined, managed,
measured, controlled, and effective \cite{CMM11}.

\begin{figure}[t]
\begin{center}
\includegraphics{figures/CMMMaturityLevels.eps}
\end{center}
\caption{The Five Levels of Software Process Maturity}
\label{fig:cmm-levels}
\end{figure}

The CMM guides organizations towards control of their processes and a culture of
software engineering excellence. This is done by determining an organization's
level of maturity and identifying the critical areas that it can improve. The
CMM assigns five levels of maturity (shown in figure \ref{fig:cmm-levels}) to
the software processes of organizations. Each level is at least as mature as the
level before it. Maturity levels indicate process capability and if they are to
be reached an organization must identify and address the goals laid out in the
level's key process areas. Of particular concern in this research is
\textit{Quality Assurance}, a key process area for Level 2: Repeatable maturity.
The goals for this key process area are enumerated below: \singlespace
\begin{itemize}
  \item \textbf{Goal 1.} Software quality assurance activities are planned.
  \item \textbf{Goal 2.} Adherence of software products and activities to the
        applicable standards, procedures, and requirements is verified
        objectively.
  \item \textbf{Goal 3.} Affected groups and individuals are informed of
        software quality assurance activities and results.
  \item \textbf{Goal 4.} Noncompliance issues that cannot be resolved within
        the software project are addressed by senior management.
\end{itemize}\doublespace

The CMM generally lays out goals and activities that an organization can
undertake to achieve process maturity. Again, though the CMM is not targetted
specifically for safety-critical systems, it provides a good place to start to
ensure that the best available practices are being utilized.

\subsection{IEEE Std 1012-2004}
The IEEE Standard for Software Verification and Validation \cite{IEEE-std-verif}
outlines processes to determine whether software products of a given activity
conform to the requirements of that activity and whether the software itself
satsifies the intended use and user needs.

The standard lists four levels of integrity (low, moderate, major, and high)
that denote the criticality of the selected software function based on its
intended use and application. High integrity systems (what we call 
safety-critical) will require larger set and more rigorous applicaiton of
verification and validation tasks.

Based on the software integrity level, the standard tabulates different
activities in the process areas of management, acquisition, supply, development,
operation, and maintenance. A \textit{process}, according to the IEEE, is 
``\textit{a sequence of steps performed for a given purpose}''
\cite{IEEE-glossary}. Activities from ``Process 5.4: Development'' of the
standard map clearly with the lifecycles of software that we focus on in this
research. for software verification and validation. At a high level, these
activities are:\singlespace
\begin{enumerate}
  \item Concept V\&V
  \item Requirements V\&V
  \item Design V\&V
  \item Implementation V\&V
  \item Test V\&V
  \item Installation and checkout V\&V
\end{enumerate}
\doublespace
This research will take a closer look into these activities and relate them to
maxims and legally imposed constraints in Chapter \ref{C:Software}.

\input{productsliability}
